Quads with gradient backgrounds can't have shadows: trying to do so results in vertex buffer stride exceeds limit on WASM builds. Maybe there is a straightforward way to increase this limit but I couldn't find it (not that familiar with wgpu)

I got a good suggestion this morning which will allow us to pack the gradient data tighter, I can do a PR with it soon. Should allow for shadow data easy peasy. The absolute max is 16 shader locations which we are hitting now, 32 bits per location.

Quads with gradient backgrounds can't have shadows: trying to do so results in vertex buffer stride exceeds limit on WASM builds. Maybe there is a straightforward way to increase this limit but I couldn't find it (not that familiar with wgpu)

I got a good suggestion this morning which will allow us to pack the gradient data tighter, I can do a PR with it soon. Should allow for shadow data easy peasy. The absolute max is 16 shader locations which we are hitting now, 32 bits per location.

Ah cool, that explains it then! No rush, I know you are working on some related things so don't want to distract from that. My main motive for looking into this was to compare the performance in browsers against CSS shadows, flutter's CanvasKit renderer, etc, since shadows and motion seem to have made a comeback in UI.

We could also save some space here by assuming the shadow color is always black and only exposing its opacity. It doesn't seem like colored shadows would be a common use-case.

After #1885 is merged should have plenty of space in the gradient attribute to add whatever you need for this PR 👍

Ok I think this should be good to review now. I added some sliders for the shadow properties in the custom quad example and updated the software renderer to also support quad shadows using essentially the same sdf approach. I'm not sure if this strategy of iterating through each pixel is acceptable from a performance standpoint, but I didn't notice much difference with my slow machine- the software renderer dev build still drops frames but not the release build.

There were a couple odd things I noticed (likely my own oversights as it's my first time working with tiny-skia 😅 ):

• When specifying a colored shadow, the red and blue channels on the tiny-skia colors used to build the pixmap appear to be flipped! Maybe there is some weird endianness thing happening here when going to bytes? I couldn't figure it out.
• Despite my best efforts there seems to be some deviation in the smoothstep function between the 2 implementations: doubling the provided lower bound in the software one gives the closest match to the shadow produced by wgpu. All the resources I looked at suggested this formula for smoothstep, so it's hard to believe that function is the issue 🤔

@nicksenger Thanks! Will take a look soon!

• The red and blue channels are indeed flipped! This is because our presentation layer (softbuffer) needs the bytes in BGRA order. You can use the into_color helper:

• tiny-skia blends colors using sRGB as if it were a linear color space (see https://webcolorisstillbroken.com/). By default, iced_wgpu transforms colors into linear RGB before blending. You can enable the web-colors feature in iced to make iced_wgpu behave like tiny-skia.

Ah thanks @hecrj , the difference I was seeing was due to the blending mode 👍 I removed the compensatory adjustments in the tiny-skia implementation and now the shadows look pretty much exactly the same when using the web-colors feature with wgpu.

Woah awesome! Thanks for doing the rebase and making those changes, they make sense to me 👍